System and method for processing checks and check transactions

ABSTRACT

A method of processing paper checks that divides into two independent paths the processing of a data file representing a check and the digital image of the check. The data files and image files are separated both in time and in space, with the data files being used to promptly initiate the transfer of funds to and from appropriate accounts, while the paper checks, at a remote location and typically lagging in time, are scanned to create digital image files and deposited as an image or substitute check if deemed ACH ineligible. The method provides for the comparison of data files to image files, based on MICR information, to find any unmatching or mismatched items for exception processing and a process to manage ACH-ineligible items as an image or substitute check. A process for translating raw MICR data to a desired format, and for identifying the proper translation to be applied, is described.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a CIP of U.S. Ser. No. 11/699,776, filed Jan. 30,2007 which in turn claims the benefit of U.S. Ser. No. 60/763,417, filedJan. 30, 2006, both of which are incorporated herein in theirentireties.

FIELD OF THE INVENTION

The present invention relates generally to a system and method ofprocessing checks and check transactions, and more particularly tocapturing data from a check at point of sale and later and remotelycapturing the image of the check for later matching of the check imagewith the check data.

BACKGROUND OF THE INVENTION A. Paper Checks—Functions Served By PaperChecks And How Paper Checks Were Physically Processed Historically

Conceptually, a paper check is a vehicle for two things: 1) the datapertinent to the financial transaction; and 2) evidence of theauthorization given by the check writer (the “payer”) to transfer fundsfrom the payer's account to the designated payee and evidence that thefinancial information was accurately extracted and recorded from thecheck.

Historically, the processing of paper check transactions was slow andlabor-intensive. When one entity (“payer”) paid another entity (“payee”)with a paper check, the payee would physically transport the paper checkto its own bank, i.e. a bank with which the payee had an account. Thepayee's bank would process the check, by reading and recording pertinentinformation about the transaction represented by the check. The payee'sbank would sort by payers' bank all of the checks it received within agiven period and physically transport those checks to the payers' banks.The payer bank would then read and record the pertinent informationabout the transaction contained on the check and make the appropriatedebit entry to the payer's account. The payer bank would then transferfunds to the payee's bank. Finally, the payee's bank would make theappropriate credit entry to the payee's account.

The physical transport and handling of the paper checks was highlyinefficient. Further, both the payer and payee banks had to process thecheck to collect and record pertinent information, with such doubleprocessing is time-consuming and prone to error.

B. Electronic Processing of Check Transaction

The digital age has ushered in a new approach to processing checks. Overthe past decade, there has been an industry transition to the electronicprocessing of checks. Electronic processing involves the recordation ofthe data (hereafter “transaction information”) presented by the checkinto a digital format which can then be transferred electronically, viathe internet or other connection between computer networks, between andamongst independent entities (such as banks and third party processors)without the need to physically transfer the paper check. Transactioninformation includes:

-   -   the amount of the check;    -   the routing number of the bank holding the account on which the        check is written;    -   the account number of the payer;    -   the check number; and    -   the date of the check.

By converting the transaction information described by the check intodigital form that can be electronically transmitted, it is not alwaysnecessary to physically move the paper check from one entity to anotherto accomplish the proper debiting and crediting of the financialtransaction. Electronic transfers of funds from a payer to a payee (or,more precisely, from the account of the payer to the account of thepayee) are facilitated by the Automated Clearing House Network (ACH).

There remain, however, a number of functions served by the paper checkthat are not served by the digital file of the transaction data. Forexample, the paper check can be used as evidence that the transactionwas authorized by the check writer, or conversely that the check wasforged. The paper check can be used as proof that there was an error inthe capture of transaction information. An endorsement and appropriatestamp(s) on the paper check provides proof that the transaction waspaid, thereby acting as a receipt. Further, when a check bounces due toinsufficient funds, the paper check can be returned and is proof thatthe payer owes the payee the designated amount and that the amount hasnot been paid.

D. Check 21—Image Exchange And Substitute Checks

To accommodate the two competing ideals of getting rid of the burdens ofhandling paper checks and maintaining a paper document that can be usedas proof when necessary, the U.S. federal government recently has passedlegislation (“Check Clearing for the 21^(st) Century Act”; hereafter“Check 21”) that creates a negotiable instrument called a “substitutecheck”. The substitute check is a paper reproduction that is generatedfrom a stored digital image of the original check. The original checkcan be scanned and its digital image stored for later use in generatingthe substitute check. The original check can then be safely destroyed ordisposed of.

If a substitute check meets the requirement of the Act, then it is theequivalent of an original paper check. A substitute check has thefollowing physical characteristics:

-   -   contains an image of the front and back of the original check;    -   bears a MICR (Magnetic Ink Character Recognition) line        containing all the information appearing on the MICR line of the        original check;    -   conforms, in paper stock, dimension, and otherwise, with        generally applicable industry standards; and    -   is suitable for automated processing in the same manner as the        original check.

E. Point of Purchase (POP) Conversion

The National Automated Clearing House Association (NACHA) developsoperating rules and business practices for the Automated Clearing House(ACH) Network and for electronic payments in the areas of Internetcommerce, electronic bill and invoice presentment and payment (EBPP,EIPP), e-checks, financial electronic data interchange (EDI),international payments, and electronic benefits transfer (EBT). NACHA'srules have, since 2000, provided for merchants to convert checks to anACH debit at the point of purchase (“POP conversion”). NACHA's POPconversion rules required merchants to obtain the explicit authorization(i.e. signature) of the consumer to debit their account. The merchantthen returns the check to the consumer along with a receipt as requiredby the NACHA POP rules and regulations. At their option, merchants maykeep an image of the check, though POP conversion rules do not requirethat the merchant keep an image of the check.

F. Back Office Conversion And New NACHA Rules

An alternative method of handling checks has been proposed by NACHA for“back office conversion” (BOC), by which merchants scan their checks ina back office, typically at the end of a day. The scanners capture animage of the check and store the image with the MICR data from thecheck. A file containing this information is then transferred to a bankor third party payment processor.

NACHA has passed this rule, to accommodate back office conversion, whichgoes into effect on Mar. 16, 2007. These rules require that a digitalimage of the front of the check be retained for two years, a noticeprovided to the consumer at point-of-sale prior to the acceptance of thecheck of payment, and a receipt provided to the consumer with languageas depicted by NACHA and the Federal Reserve under Regulation E.

SUMMARY OF THE INVENTION

The present invention provides a system and method for converting checksto debit entries by which data from the checks is captured at the pointof purchase and this data is used to promptly process a deposit to themerchant's account via a third party payment processor (TPPP).Meanwhile, the paper checks collected by the merchant are physicallytransported from the merchant's place of business to another locationfor scanning and image capture. Each check image is stored inassociation with its MICR (Magnetic Ink Character Recognition) line andindexed for future retrieval purposes. The TPPP receives data files fromthe merchant with the MICR and amount information; the TPPP receives thephysical items for scanning and imaging. The TPPP executes a matchingoperation between the image files and the data files, matching imagefiles with data files based on the MICR, amount, and auxiliaryinformation. Routines are provided for handling image files with nomatching data file, data files with no matching image files, and imageand data files that find a MICR match but include some discrepancy intheir data (e.g. amounts do not match). The non-ACH items that find asuccessful match, are rendered via image exchange for settlement.

With this system and method of processing checks, the data file is usedto promptly process the transaction (and send a credit to the merchant'saccount) through a third party payment processor. In other words, thethird party payment processor can initiate the credit to the merchant'saccount before the image of the check is matched up to the data file, orperhaps even before the image of the check is made for ACH eligibleitems (i.e. first-party consumer checks and business checks that do notcontain an auxiliary on-us field). In this manner, the third partypayment processor can provide the merchant with improved fundsavailability, while still providing for the storage of the image of thecheck, and destruction, as required by rules and regulations governingcheck processing.

This system and method allows for the storage and use (e.g. reporting)of a variety of data regarding each check that may be captured at thepoint of sale. Such data includes MICR line (routing number, accountnumber, check number), dollar amount, store identifier, lane/cashieridentifier, point-of-sale date, and other merchant defined auxiliaryinformation.

The system and method offers the further advantage that merchant's arerelieved of the task, cost, and risk of scanning and destroying thepaper checks themselves, relying instead on a secure, high-volumescanning operation to obtain digital images of the checks. This methodfurther provides for the digital archiving of check images forprescribed periods of time.

In typical practice, many merchants have more than one location, and thesystem and method provide for service to more than one location of amerchant. Further, the system and method provide for service to morethan one merchant. The system and method for processing checktransactions is generally automated to allow processing of a high volumeof check transactions from a number of merchants and to accommodatemultiple locations of the merchant(s).

A method for processing paper checks according to this system includingthe steps of: at the merchant's point of purchase, capturing the amountof the transaction and associating that amount in a data file with MICRinformation for each paper check, or batch of paper checks; sending abatch of said data files representing said batch of checks to a thirdparty payment processor without an image file; physically transportingsaid batch of checks to a location remote from said merchant; scanningsaid batch of checks thereby creating a digital image of the checks and,for each said check, associating said image with said check's MICRinformation; and comparing said image files with said data files to findmatches.

BRIEF DESCRIPTION OF THE DRAWINGS

An exemplary version of the check processing system and method is shownin the figures wherein like reference numerals refer to equivalentstructure throughout, and wherein:

FIG. 1 is a schematic representation of a prior art method of convertinga check at the point of purchase (ACH code POP);

FIG. 2 is a schematic representation of a prior art method of convertinga check in the back office (Traditional BOC model);

FIG. 3 is a schematic representation of a system and method forprocessing checks that entails transferring check data independently ofa check image, and later connecting check images with their respectivecheck data (Solutran model);

FIG. 4 is a flow chart showing the system and method of FIG. 3, withadditional details shown regarding processing of exceptions (Solutranmodel);

FIG. 5 is a deposit ticket used in the system and method of FIGS. 3 and4;

FIG. 6 is a flow chart showing a portion of the system and method ofFIG. 4, with details of the process for matching data files to imagefiles (Solutran model);

FIG. 7 is an illustration of the format of the data file sent from amerchant to a third party payment processor, according to the system andmethod of FIGS. 3 and 4;

FIG. 8 is a flow chart showing a process for handling MICR data from themerchant data file in a system shown in FIG. 3; and

FIG. 9 is a table used in conjunction with the MICR handling processshown in FIG. 8.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT(S)

FIG. 1 shows a prior art system and method for converting a check at thepoint of purchase (POP conversion). A consumer 1 pays for goods orservices with a check 2. At the point of purchase terminal 3, themerchant keys, or applies amount captured at POS, into the terminal theamount of the purchase. The merchant also passes the check through aMICR (magnetic ink character recognition) reader to capture theconsumer's account number, routing number of the financial institutionholding the account, and the check number. Optionally, the merchant mayalso capture a digital image of the check. The merchant determineseligibility based on current NACHA rules, and returns the check to theconsumer for the ACH eligible items. The merchant then transfers a file4 containing this captured information to a third party paymentprocessor (TPPP) 10. Typically, the merchant would periodically(typically daily) send batches of these transaction files. The TPPPwould then process the transaction as an ACH payment.

FIG. 2 shows a prior art system for converting a check in the merchant'sback office. With this system, the merchant scans their checks inbatches in a back office, instead of at the purchase terminal.

FIG. 3 shows a system 1 and method of processing checks by which thephysical checks and their data files are initially (when they leave themerchant) separated. FIG. 3 depicts the system generally andconceptually. (FIGS. 4 and 6 depict the process, or portions of theprocess, with greater detail.) Ultimately, the data files are matched upto the image files for reconciliation. More specifically, a consumer 30pays a merchant with a check 32. At the merchant's point of purchase 34,the cashier keys in the amount of the purchase, or applies amountcaptured at POS, and passes the check through a MICR reader that readsthe MICR line of the check and converts the MICR information to digitalform. The MICR reader communicates directly or indirectly with the POSdevice that captures the amount, creating a digital record for eachcheck transaction.

Periodically (typically daily), the merchant sends a data file 36 to athird party payment processor 38, reflecting a batch of such checktransactions that have occurred during the period. More specifically,the merchant computer or server transfers the POS data file 36 to a TPPPcomputer or server over a computer network via a pre defined filetransfer protocol. The data file 36 contains at least the followinginformation about each transaction: the MICR information (routingnumber, account number, and check number) and the amount. The data file36 also includes an identifier for the merchant, location identifier,and a transaction identifier, with at least one of these identifiersbeing unique or with some combination of these identifiers being uniqueacross the system that typically involves multiple merchants, each withmultiple locations and with multiple transactions being processed withinthe reporting period.

The TPPP decisions the received data files, determining which areeligible for processing through the Automated Clearing House (ACH) 40,and which are not. ACH transactions are passed through the ACH networkfor processing and appropriate debiting of the consumer's account 42 andthe crediting the merchant's account 44, respectively. Morespecifically, the TPPP computer sends data files reflecting the ACHtransactions into the ACH network (i.e. the computers or servers onwhich the ACH network operates) via pre-defined file transfer protocol.

The merchant 34 periodically physically transfers a batch 50 of itspaper checks to a secure courier (e.g. Brinks, UPS or U.S. postalservice) 52 for physical delivery to a secure, high-volume scanningoperation 54. This scanning service might be provided by the TPPP or maybe provided by an independent company, typically in accord with acontractual relationship with the TPPP. The scanning operation 54 scansthe checks, creating digital images of the checks that are stored in adigital file in association with their MICR information on the imager'sserver or computer. Physical checks are securely stored until they aredestroyed, based on client specification.

Finally, the image files of the checks are matched to the data filesrepresenting the checks using the MICR line, thereby linking the imagesto the data files. This is achieved by assigning a unique number to eachdata record, and upon a successful match, indexing the data and imagewith the unique number for future access in retrieval needs. The MICRline, including the dollar amount, of a check is typically unique andthis affords a one-to-one matching based on the MICR line.

This matching operation may be performed on a computer or serveroperated by the TPPP 38 or by the scanner 54 or by some other entityaffiliated with or associated with the TPPP. This matching step isperformed to identify any discrepancies between the data files and theimage files which represent the checks so that these can beinvestigated. It will be appreciated that before the matching operationtakes place, the matching computer must have access to both the POS datafile and the image files created by the imager. When the matching stepis performed by the TPPP, the imager transfers the image files from theimager computer to the TPPP computer over a computer network via apre-defined file transfer protocol. When, alternatively, the matchingstep is performed by the imager, the TPPP transfers the POS data filesfrom the TPPP computer to the imager computer over a computer networkvia a pre-defined file transfer protocol. When, as yet anotheralternative, the matching step is performed by a third party, the TPPPtransfers its POS data files and the imager transfers its imager filesto the matcher's computer over a computer network via a pre-defined filetransfer protocol.

FIG. 4 shows additional details of portions of the process depicted inFIG. 3 and illustrates the divergent flows for the data collected at thepoint of sale reflecting the check transactions (110) and for thephysical checks and the images of those checks (200). At the point ofsale, when a customer presents a transaction document to pay for goodsor services, the merchant passes the document through a MICR reader toread the MICR line of the document. In addition, the merchant keys in orotherwise enters an amount for the transaction at the point of saleterminal. The amount and the MICR information are associated in a datafile including a merchant identifier, a store identifier, and othervarious data associated with the transaction A data file containing allof the transactions for a period of time is sent, periodically,typically daily, from the merchant to a third party payment processor(step 120, FIG. 4). The structure of a merchant's data file 125 isillustrated in FIG. 7. The fields identified in this file are asfollows:

A File Header Record: Record type: a predefined indicator indicatingthat the record following, until file trailer indication, is a filerecord Version: predefined identifier, identifying a file format versionFilename: assigned by a merchant Account Number: an identifier unique tothe merchant, assigned by the TPPP Merchant's a prescribed identifierfor the merchant's bank Bank ID: File items: a count of the number ofdetail records in this file transmission

A Batch Header Record: Record type: a predefined indicator indicatingthat the record following, until batch trailer indication, is a batchrecord Location: identifier for a store location Sale Date: date of saleACH Company Name of merchant company that will appear Name: onconsumer's bank statement (assigned by merchant) ACH CED: An optionaladditional field for a merchant description that may appear onconsumer's bank statement (assigned by the merchant) ACH CDD: Anoptional additional field for merchant's discretionary data (assigned bymerchant)

A Detail Record: Record type: a predefined indicator indicating that therecord following, until detail record trailer indicator or batch trailerrecord, is a detail record Item type: indicates the type of document ortransaction (e.g. business check, merchant payroll, non-standard checksuch as WIC, traveler's check, gift certificate check), personal checkor Canadian Amount: Numeric dollar/cents amount of transaction Raw MICR:MICR line, consisting of digits, spaces and TOAD delimiters) Parsed RT:Parsed Routing Number, an optional field used when merchant's MICRreader parses the MICR to identify the routing number Parsed ACCT:Parsed Account Number, an optional field used when merchant's MICRreader parses the MICR to identify the consumer's account number ParsedCHECK: Parsed Check Number, an optional field used when merchant's MICRreader parses the MICR to identify the check number

A Batch Trailer Record: Record type: a predefined indicator indicating abatch trailer record Batch Items: number of data records in this batchTotal Amount: total dollar/cents amount of all detail records in thisbatch

A File Trailer Record: Record type: a predefined indicator indicating afile trailer record

This data file is sent via data connection, such as from one computernetworked, one way or another, to another computer, via a predefinedsecure socket layer (SSL) file transfer protocol (FTP) As shown in FIG.4, the payment processor loads or assimilates the merchant's file intoits data system, assigning to each transaction record an itemidentifier, an identifier of the type of the record and calculates adate that the original item or image is expected for matching andarchiving (step 130).

In the embodiment of the system and method illustrated in FIG. 4, aprocess (131) is followed to translate the MICR data that was includedwith the merchant file received by the TPPP into a desired predeterminedformat.

A bit of background is required before describing the MICR-handlingprocess (131). Point of sale scanners and data capture systems aremanufactured by various entities. Treatment of the MICR data by thesepoint-of-sale systems can vary somewhat. Therefore, it is advantageousfor the check processing system and method to include features forhandling a variety of MICR data formats.

“Raw” MICR data is a single field having a string of alpha numericcharacters. Within the string are the “components” of a MICR line; thesecomponents are the routing number, the account number, the check number,the amount of the check (not shown in the MICR line of the check, butadded with data from the point of sale terminal), and a dash symbolindicating a separation between fields. (The dash is not always presentor required.) Predefined alpha-numeric markers designate the start ofeach component within the raw MICR string. A common protocol for a rawMICR data is called “TOAD”, wherein a first “T” precedes digitsrepresenting the routing number and a second “T” is located at andindicates the end of the routing number; a first “O” precedes digitsrepresenting the account number and check number and a second “O” islocated at and indicates the end of the account number and check number;an A precedes digits representing the amount of the check, and the Dprecedes a dash. There are, however, alternative protocols fordelineating the components of the MICR data within the raw MICR string;i.e. manufacturers of point-of-sale data capture systems may usealternative protocols. For example, IBM's point of sale systems insteaduse a “T” preceding the routing number, and “A” preceding the accountnumber and check number, a “$” preceding the amount and a dash separatesother fields. Other manufacturers may provide still further alternativeprotocols.

An embodiment of the system and method of the present inventionaccommodates a variety of raw MICR protocols through process (131),illustrated in FIG. 8. The TPPP receives a merchant's data file (120),as previously described. This file includes raw MICR data formattedaccording to the protocol of the merchant's point of sale system. TheTPPP determines what protocol was used for the incoming raw MICR, thentranslates the raw MICR into the desired format and then stores thattranslated raw MICR in association with an item ID along with othertransaction data (140). More specifically, following the flow chart ofFIG. 8, the system checks (132) to determine if the data in the file isaffiliated with a point-of-sale system (“POS system”) of a first type,Type A, and if so applies (133) a corresponding translation, TranslationA, to yield raw MICR in the desired format. (The POS system employs ascanner connected to various other components, such as a sales terminaland affiliated hardware and software.) If the data in the file is notaffiliated with a POS system of Type A, then the check-processing system1 determines (134) if the data in the file is affiliated with a POSsystem of a second type, Type B, and if so applies (135) a correspondingtranslation, Translation B, to yield raw MICR in the desired format. Ifthe data in the file is not affiliated with a POS system of Type B, thenfurther checks (indicated by the dotted line 136) are employed until theproper POS system is identified, so that the corresponding translationcan be performed. Some POS systems may provide raw MICR in a format thatdoes not require translation (i.e. is already in the desired format), inwhich case no translation step is performed.

The database supporting the check-processing system 1 includes a tableof POS system systems in association with a definition of their raw MICRprotocol. FIG. 9 shows an example of a translation table 137,illustrating how the alpha-numeric symbols of a “4610” system (i.e. T,A, $, —) used to delineate MICR components translate into symbols of aTOAD system (i.e. TOAD, respectively).

In some cases, the merchant's point of sale system may “parse” the MICRdata, to divide it into its component parts. In other words, instead ofgenerating a raw MICR line (in which is included the routing number,account number, and check number), the system may divide thisinformation into its components and store each component in separatefields. Merchant files from such systems will provide “parsed” ratherthan raw MICR data. To accommodate this parsed MICR data, theMICR-handling process (131) translates this parsed data by combiningthese separate fields and adding appropriate markers, to yield a rawMICR string of the predetermined, desired format.

Another feature that supports the MICR translation capability is theability to determine what kind of point-of-sale system is affiliatedwith the data in an incoming merchant file. This could be accomplishedin several ways. For example, the merchant data file may include a fieldthat identifies the point-of sale system, according to a predefined codeor designation. Alternatively, the POS system type might be stored inassociation with a merchant or a location ID, so that upon receipt ofthe merchant file, the check-processing system 1 can assign or look upthe POS system type used by that merchant or location.

In short, the MICR-handling process (131) takes files merchant datafiles having MICR data in varied formats and translates it into adesired predetermined format. It does this in an automated way, callingupon previously-stored POS system-specific translations, by recognizingthe translation that is required, and by making that translation.Automation is accomplished through software running on computer hardwareand performing operations on data in digital form. This automation isparticularly useful in handling data from many different merchants orlocations who use varying protocols for their MICR data.

These records are then stored or archived (140), and processedaccordingly as explained further below.

For each transaction record, the payment processor makes a determinationas to whether the transaction is eligible for ACH processing or not(150). ACH eligible items include first party consumer checks andsmall-size corporate checks. (Corporate checks come in two sizes: a“small” size that is approximately the same size as a consumer check,and a larger size.) ACH ineligible items include money orders, WICchecks, travelers checks, large-size corporate checks, governmentchecks, and others as identified under the NACHA rules and regulations.For those records that are ACH eligible, the payment processor createsan ACH file that includes the merchant's name, company entrydescription, ACH tracer identifier, the MICR line, and the amount of thetransaction according to NACHA rules and regulations for ACH BOCprocessing and various other information. (160).

The payment processor, in typical commercial practice, will providepayment processing services to a number of merchants. On a periodicbasis, typically daily, the processor will batch the records of the ACHeligible items by merchant (170), and will submit the batched records inan ACH file to the ACH Network for settlement (180). Thereafter,settlement to the merchant's bank account is made, followed by balancereporting, a confirmation file and a BAI file, typically on the nextbusiness day (190).

As noted above, the physical transaction documents that customerspresent at a point of sale follow a path (200) that is independent ofthe path (110) of the data reflecting the transaction. At step 100, amerchant gathers a number of transaction documents to be processed. Themerchant will do this on a periodic basis, typically at the end of eachday. The merchant bundles the transaction documents together andprepares a deposit ticket 201, shown in FIG. 5 to correspond to thebundled documents. The deposit ticket provides spaces for the merchantto summarize the bundled documents with the following data: thepoint-of-sale date 202, the total item count 203, the total depositamount 204; an identifier for the store location 205 and an accountidentifier 206 for the account into which funds should be transferred.Optionally, a pre-printed form, or multiples thereof, are provided tomerchants, with the store location 205 and merchant's bank accountidentifier 206 pre-printed. Further, optionally, the pre-printed formmay include a MICR line 207, with a first portion 208 reflecting thelocation identifier and a second portion 209 reflecting the depositaccount number. This MICR aids in later processing of the deposit slipby the check imager. It is a further option, to pre-print the merchant'sname on the deposit tickets.

With reference to FIG. 4, the bundled transaction documents aredelivered to an image processor. FIG. 4 reflects two examples of how thedocuments may be transported to the imager. A first option is for acourier to pick up the bundled documents from the merchant (210), andthen for a check shipping agent to pick up the bundle from the courieror from the courier's consolidation location and deliver them to theimager (230). An alternate delivery method is for the merchant to dropthe bundled documents into a secure carrier (e.g., U.S. Postal Serviceor United Parcel Service) mail drop (220) for delivery to the imager.

The imager receives the deposited bundle of documents (or typically manydeposited bundles of documents, each from one location of a merchant),scans the deposit ticket 201 and uses optical character recognition(OCR) software to interpret the information presented on the ticket 201.(Where a MICR line 207 has been pre-printed on the deposit ticket 201,it may be read by a MICR reader, then scans the ticket and applies OCR,linking the data obtained from the OCR with the MICR-obtained data.) Theimager performs a balance to confirm that the amount indicated 204 onthe deposit ticket 201, FIG. 5, matches the sum of the documents bundledor included therewith (240, FIG. 4).

As shown in FIG. 4, the imager then captures images of each document(250). More specifically, the imager scans the front and back of everyitem, captures the MICR and one of or both of the courtesy amount andlegal amount using OCR software (265). The front and back images arestored in association with the MICR and amount for item retrieval andexception management (270). The merchant bank account identifier, takenfrom the deposit ticket that accompanied the batch of checks, is alsostored in association with the image, MICR and amount. In accord withfederal regulation, the original physical documents must be securelystored until items are destroyed (280).

Next, the process includes an attempt to match each image record to adata record (290), where the data record was generated through path 110and archived in step 140, described above and includes the MICRinformation, the dollar amount and an item identifier, merchant bankaccount, point-of-sale date, and location identifier. More specifically,for each image record, the data files are searched to find a data recordwith a “matching” MICR and amount. (Alternatively, for each data file,the image files are searched to find a data record with a matching MICRand amount.) “Matching” records are indexed to connect the image withthe data.

The system provides for the setting of parameters as to the degree towhich the image record and a POS data record must be the same for themto be deemed “matches” or “matching”. More specifically, the parametersdetermine how closely various fields must correlate for records to bedeemed “matching”. A probability as to likely matching may be determinedand used to assist both the identified matches and to aid in processingunmatched records. Fields used in performing comparisons between imagerecords and POS data records include: merchant bank account identifier;sale date; check dollar amount; MICR data (raw or parsed).

For each image record for an ACH eligible item for which a matching datarecord is found (300), the indexed record (containing the image anddata) is archived (310). For each image record for an ACH ineligibleitem for which a matching data record is found (320), the indexed record(containing the image and data) is archived and an image exchange fileis prepared (410) that includes the image, the MICR, the merchant's bankaccount number and other information as required for image exchange(330). This image exchange file is then transferred via the bankingnetwork (420).

Finally, for the ACH-ineligible matched items, settlement is provided tothe merchant's bank account based on availability and reported viabalance reporting and a non-ACH deposit file, typically the nextbusiness day.

Situations in which no match is found for an image record or for a datarecord after the date that the image from the paper document wasexpected, are subject to exception processing (350). FIG. 6 shows threecategories of exceptions and the steps followed for each type ofexception. As noted above, each data record includes a date by which theoriginal item is expected and will be ready for matching and indexing.This projected date takes into account a bit of a lag time for thetransport of the physical document. The image record may be missing forany of a number of reasons, including that it has been delayed intransit, that it has “piggy-backed” to another document so that it wasmissed in the scanning, or that the document has been lost. When theprojected date passes, with no image record appearing, that data recordis processed as “expected, not received” (540). The situation is thenresearched (560)—and, based on the results of that result, a decision ismade as to what to do with the item.

The researching 560, which is done manually, automatically or via acombination of manually and automatically, is presented to theresearcher automatically based on probability matching. Research mosttypically involves manually querying a database(s) that stores imagerecords and/or POS data records before a final decision has been made.After the research step (560), the item is decisioned for deposit (570).In some cases, the research step will reveal that there does indeedexist a matching image record, and, in such cases, the items will beidentified as a match, then presented for settlement (580). In othercases, it will be determined during research that either a POS datarecord or an image record requires adjustment or repair and that uponmaking such repair, it can be matched; in such cases the item is thenflagged as “matched” and presented for settlement (580). In still othercases, when research reveals that there is no viable matching record,the POS data record can be placed back in the queue of records that willbe subject to item by item matching (290) on another day; this will givethe image record additional time to appear.

Finally, in some cases, it will be determined that the POS data recorddoes not represent a transaction that ought to be processed. Thisoccurs, for example when an errant POS entry is made and not deleted.Such POS data records will be removed 560 from the exception queue (590)and identified in a database field to indicate that no further attemptswill be made to match it.

A second category of exceptions is “received, not expected” (600). Theseitems result when there is an image record for a transaction, but nomatching data record. In such cases, the item is researched (610). Aswith the “expected not received” items, a decision is made (620) as towhether the “received not expected item” ought be processed forsettlement, upon finding a match or discovering a repair to be made tothe record to allow a match. Such now-matched items are then presentedfor settlement (630). Items for which no match or repair can be made areremoved from the exceptions queue (640). Typically, such unmatchableitems occur when a coupon, gift certificate, or non-negotiable paperinstrument is errantly included among the scanned document. Theserecords are assigned a type to indicate that they are non-cash items(640) and are not presented for settlement.

A third category of exceptions is “data mismatch” (700) where a match isfound based on the MICR information, but some portion of the data fromthe image record does not match with the data record. For such cases,the records are researched (710) and an appropriate adjustment orcorrection (720) is made and the transaction is presented for settlement(730). For records for which no match can be found and no repair iscalled for, the non-matching image record or POS data record is removedfrom the exception queue (740) and is not presented for settlement.

Yet another step (not pictured) in processing exceptions may includereporting of exceptions by the TPPP to the merchants.

In a preferred method, the merchant's account can be credited at theinitiation of the third party processor, based on the data file, beforethe image of the check is matched to the data file, or perhaps evenbefore the check is imaged for ACH eligible items. ACH ineligible itemsare rendered processed through the Image Exchange Network upon asuccessful data and image match.

It should be noted that this system and method has been described in thecontext of a coordinated effort between merchants, a third party paymentprocessor and a high-volume image scanning entity. The system may alsofunction with additional or fewer parties and with other divisions oflabor amongst the parties. For example, the matching, indexing andexception processing steps (290) are described as being done by theTPPP, but might instead be done by the imager or another entity. Asanother example, the third party payment processor might perform thescanning task. Such shifts in the division of labor would be facilitatedwith appropriate file transfer steps. Although an illustrative versionof the device is shown, it should be clear that many modifications tothe device may be made without departing from the scope of theinvention.

1. A method of handling a variety of raw MICR formats in a checkprocessing system, comprising: a) storing in a database two or morepredefined raw MICR formats; b) storing in said database, in associationwith said formats, a translation to a desired raw MICR format; c)receiving a merchant data file representing check transactions includingraw MICR data; d) storing in said database in association with amerchant identifier, an identification of a raw MICR format for saidmerchant; e) for said received merchant data file, applying a predefinedtranslation to generate raw MICR data in a desired format forsettlement.
 2. A method for processing paper checks, comprising: a) atthe merchant's point of purchase, capturing the amount of thetransaction and associating that amount in a data file with raw MICRinformation for each paper check, or batch of paper checks; b) sending abatch of said data files representing said batch of checks to a thirdparty payment processor without an image file depicting the check; c)storing in a database two or more predefined raw MICR formats; d)storing in said database, in association with said formats, atranslation to a desired raw MICR format; e) receiving a merchant datafile representing check transactions including raw MICR data; f) storingin said database in association with a merchant identifier, anidentification of a raw MICR format for said merchant; g) for saidreceived merchant data file, applying a predefined translation togenerate raw MICR data in a desired format; physically transporting saidbatch of checks to a location remote from said merchant; i) scanningsaid batch of checks thereby creating a digital image of the checks and,for each said check, associating said image with said check's raw MICRinformation; and j) comparing said image files with said data files tofind matches.
 3. A method according to claim 2, further comprising thestep of: f) before step e), crediting the merchant's account for thetransaction.
 4. A method according to claim 2, further comprising thestep of: f) providing exception processing procedures for any unmatchedor mismatched image and data files.
 45. A method according to claim 2,wherein said comparison is done based on raw MICR information.